【Bullshark】handle_consensus_output() in consensus_handler.rs
MystenのGeorgeの返信に基づく
consensus_handler.rs
コミットされたサブDAGをもとに最終的な実行トランザクションを基本的にガスプライスに従ってシーケンスする
anchor leaderがどのようにバリデータからローカルビューを受け取るは書いていない
in ConsensusHandler
ConsensusSubDag構造体も同じファイルにある
この構造体は，sub_dagとbatchesフィールドで構成されていて，コンセンサスの出力であるサブDAG（証明書）とそれに対する全てのバッチを表している
つまり，Bullshark実行後の構造体の一つである
TODO: CosensusOutputはいつ更新されているのか？
run_notify()で使っている
state.handle_consensus_output(message).await;
spawn_subscriber()でrun_notify()を使っている
Executor::spawn()でspawn_subscriber()を使っている
トランザクションの実行ドライバー
handle_consensus_output()を読んだ時点でBullsharkで理解していないことを解決する
handle_consensus_output()でtxの順序付けは確定できるが，アンカーリーダーのコミットに関する順序付けについては記述されていない．
Yes
handle_consensus_output()でサブDAGをコミットするかどうかを決める
サブDAG内の各証明書とバッチを処理します。これは順序付けの主要な部分
code:.rs
if matches!(
self.epoch_store
.protocol_config()
.consensus_transaction_ordering(),
ConsensusTransactionOrdering::ByGasPrice
) {
let _scope = monitored_scope("HandleConsensusOutput::order_by_gas_price");
order_by_gas_price(&mut sequenced_transactions);
}
ここでトランザクションの完全な順序付けを達成する
code:.rs
consensus_commit_batch
.commit(checkpoint)
.expect("Failed to commit consensus commit batch");
関数のプロセス
トランザクションの処理のみを記載し，マトリクスなどの統計情報などは除外する
最後にコミットされたラウンドとConsensusOutputのリーダーラウンドと違うことを確認する
トランザクションが重複していないか，すでに処理されていないかを確認
ガスフィーに基づくトランザクションの順序付け
以下はトランザクションのコミット，ブロックチェーンへの書き込みという点では不要
チェックポイントを作成
consensus_commit_batch.commit(checkpoint)でコミット
チェックポイントはスナップショットとして機能
トランザクションのコミットの後に行われているはず
これもまあ不要
process_consensus_transactions_and_commit_boundary()
すけージューリングで次のラウンド以降のためのものの準備か
質問
回答は上に記載
まだ理解できていないことについての質問を作る．
SuiのBullsharkコンセンサスプロトコルの部分同期バージョンについて，以下の質問に技術的・学術的に詳細に解説してください．
a1. Bullsharkのアンカーリーダーの選出アルゴリズムは，Bullshark::update_leader_schedule()に処理について記載されていて，ステーク量による重みづけランダムネスによって選出されるということで間違いないですか？
a2. ラウンドロビンで実行されているというのはどのような点でそのようにいうことができるのですか？
a3. ラウンドロビンであることが公平性を満たす要因となっていますか？なっているとするならば，なぜそうなるのかを証明してください．
b1. アンカーリーダーのコミット対象のサブDAGではなく，その中身のtxの順序付けについて，ガスプライスとタイムスタンプのみをもとに順序付けしていますか？
b2. Suiはアンカーリーダーとラウンドを知っていて，アンカーリーダーをコミットするために委員会のバリデータからの投票を待っている？
その通り
c1. DAG構造を使った各ノードへの投票を行うバリデータが複数いて，そのバリデータがfaultyである可能性もあるとき，quorum intersectionとはなんなのかという概要と，この場合での役割と機能について説明してください．
c2. quorum intersectionを満たすためにサブDAGをコミットする条件としてf + 1の投票が求められているが，n - fよりも条件が緩いように考えられるがそれはなぜですか？
d1. アンカーリーダーへの投票と直接的コミットは同じ意味で，投票はバリデータによる署名によって達成されますか？
d2. コミットに必要な > f + 1 の投票におけるfは遅延のみですか？もし悪意のあるトランザクションを含んだとしてもNarwhalでDAGを作るまでに除外されるはずだと考えています．そして，遅延とはローカル上でアンカー間のパスを持っていないバリデータによるコミットで問題が起きているはずです．
d3. NarwhalメンプールプロトコルからBullsharkプロトコルへDAGで構造化された証明書を渡すのはバリデータではなくて，Suiシステムですか？
d4. アンカーリーダーであることを受信するのは，リーダーから？ゴシップ（他のバリデータによる通信）から？Suiから？どこからですか？
Narwhalも含めるが，Suiの並列実行, parallel executionの実現には，独立したトランザクションの特定とtx間の依存関係の特定のプロセスの中で，Sui Move言語のobject-centric data modelが貢献している
Evanはスケーリングにも寄与https://scrapbox.io/files/671cb1caa7251bcd74aaf5d8.png
しているとのこと，その通りやね
依存関係についてはグルーピングが行われている
グローバル・ストレージはMap<ObjectID, Object> というのは？
所有オブジェクトと共有オブジェクトの完全な境界線について
以下の所有オブジェクトと共有オブジェクトの完全な境界線はどこにあるのか？
所有オブジェクトのシンプルなtxのためのアルゴリズム
例
P2Pトークン転送、NFTの大量鋳造、投票、dAppsでのメッセージ送信
コンセンサスレス
NFTの大量mintは取引はDeFiのアクティビティに関連する取引から分離されるため、コンセンサスを得る必要がなく（すなわち、グローバルな順序付けが不要）
Network Communication layerとconsensus layerが分かれているからコンセンサスレスも実行できるのである
誰でも読み書きできる共有オブジェクト
例
AMM、公開入札によるオークション、あらゆる取引を受け付けるセントラル・リミット・オーダーブック（CLOB）など
Monas経由のストレージの攻撃について
クラウドストレージは常にオンライン状態になる？？
ブロックチェーンアドレスのアドレスのようにアドレスごとに認証する？
自身のアドレスである真正性は，署名と属性ベース暗号？？